終於來到了這三十天發文的最後一天了，在完成了所有文章後回頭再重新瀏覽一次後總是覺得缺少了一點東西，一個是有些topic因為時間的關係無法講的很詳細，另一個是少了真實案例總覺得好像沒有說服力，測試到底可以帶來多少好處，難到只是多了一些可說嘴的技能？還有除了理論上的好處那真實情況是如何呢？所以這裡會用目前公司的實際案例來舉例說明。目前的公司是一個合法的跨國匯款的線上服務，除了對企業客戶後端API串接外也有對一般終端客戶服務的Android & IOS Application，讓客戶可以不透過銀行進行繁複的手續時間及付出高額的手續費就能即時與低費用的進行跨國匯款，當然要執行這些業務都要取得當地政府的合法金融執照。

在公司的C2C流程中不需要花俏的介面，我們要做到的就是穩定的與後端API串接讓客戶可以成功的完成交易，這類型的金融服務程式不像娛樂型程式一樣，顧客可以每天看很多次且每次都停留很短的時間，客戶一個月可能只會做幾筆交易，但每次的使用都會為公司帶來收入，因此交易穩定度是這類程式的基本要求，再來就是有竸爭力的手續費，但這是Business Model的範疇不在討論範圍。

在我接手開始導入測試之前我們的UI架構已經是用MVP的方式設計，但是只重其形不重其意，一樣有設計介面把邏輯分離，但因為沒有寫單元測試所以不斷的把presneter裡摻雜了許多ui reference直接與ui溝通(這是大忌)，不是利用介面來與ui溝通，因此在開始想做單元測試的時候才發現無法寫單元測試。所以我採取的策略是利用開發新模組的時候導入BDD/TDD的開發模式，也就是加入一個新的UI功能時候再來實現測試先行的開發。在BDD/TDD的開發過程中，當我把test case都準備好，我可以先行把Presenter的邏輯實作完成並利用test case來間接說明每個presenter裡的function作用，另一位一起開發的同事就能很安心的分工幫忙做View這部份的建置。當PM問我說你有測試了什麼東西，我也可以很快的拿出test case來說明。這次的經驗告訴我如果在比較大的task裡先花費一定的時間去做test case的開發在後面的維護上會有效率許多。

在完成了新的模組的TDD模式開發後，開始針對一些舊有的程式碼在每次的task裡做refactoring改成MVP或MVVM，不過這要看原本元件複雜度如何，像包含太多UI互動的頁面就會不更動，因為會導致的side effect可能太大找自已麻煩。通常這種很綁了一堆元件複雜的頁面也是集功能大成於一身的主要頁面，例如像每個application的Landing page，如果不能測試它的話會漏掉大部份的scenario等於沒測試，這時候就會利用Integration Test來幫忙，用一魚兩吃的方式，除了UI元件流程會測試到之外當然也會包含這些元件所操作的function邏輯部份。

最後只有靠mock data測試local的環境可能還不太夠，這只能確定我們的程式邏輯沒錯。但因為有不同通路及不同匯率的關係，可能我們測試的data在某個時間點真實環境就不存在了。所以這個匯款application的每個步驟都需要跟backend做確認，進一步說這個app與真實環境互動做測試同樣也很重要。所以我們利用Appium去建構Android & IOS的test case並且在AWS Device Farm上做定期的測試來確保從client到server端都沒問題。

對developer以外的人來說end to end test是最直接可以知道程式品質的測試，但是對developer來說end to end test是最討厭的測試。因為end to end test與真實世界互動，即使你沒修改程式也常常有不預期的錯誤發生，developer要花很多時間去trace bug。而integration test與unit test用mock data只要不對production程式改動就不太可能會有問題發生。但只要有修改程式碼，unit test和integration test就是第一線和第二線的把關角色，可以快速的找到問題，所以我自己理想的測試時間分配來說

• Unit test
  • 佔60%以上的時間來開發，一但production任何的修改而發生測試錯誤，能夠快速的被查覺及訂正。
• Integration test
  • 佔30%來開發就好，因為大部份的邏輯都在unit test被測試了，這邊只要花時間去測試元件的Action以及Display是否能正常到下一步，而元件的Action及互動也會包含部份的邏輯一併被測試到。
• End to end test
  • 佔比10%以下，與外界互動的主要流程需要implement，沒有互動的就不要花時間去寫，應該在integration的時期來測試就好，所以不需要常常新增。
• QA engineer
  • 在最後關頭做人工測試，應測試special case，但不應該再花時間測試test case重複的部份

花了三十天的時間整理一下自己對測試的心得及看法，雖然無法鉅細穈遺的把所有topic都講的很詳細，但是該提到的都有提到，細節的部份就留給大家慢慢摸索，現在就開始動手計畫測試吧。